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[0001 ] It has long been known that the ability to move objects dynamically from computer to computer is useful For 
example, moving objects allows the system to load balance among computers. In addition, it allows the system to 
dynamically cluster objects that communicate frequently, reducing network traffic and improving overall system per- 
formance. 

[0002] However, current systems that allow objects to be relocated (migrated) suffer significant drawbacks typically 
requiring either a special purpose programming language (or special purpose modifications to a general punpose lan- 
guage) or a special purpose operating system. In the former case, the programmer must develop new skills and adorn 
their code with additional syntax to exploit object migration. In the latter case, the resulting programs are limited to 
execution on sparsely deployed systems. 

[0003] The present invention, relating to Dynamic Object Distribution (DOD), describes a system that suffers neither 
of these limitations. In the preferred embodiment, the programmer simply writes his program in the Java programming 
language (Java is a trademark of Sun Microsystems) without adding any special syntax or notations. The program 
then executes on standard Java Virtual Machines (JVMs) which are widely deployed in the industry. 
[0004] Object migration has been studied extensively in academia as well as in industry. Systems such as the v- 
kernel enable page-based migration on systems running the v-kemel, however, systems without the v-kernel cannot 
perform migration. Because the v-kemel requires operating system modification, it is not widely used. Systems such 
as Amber from the University of Washington migrate objects among nodes of a multi-processor computer. However 
Amber requires the program to be written in a special language. The Amber runtime is also not widely used A major 
benefit of the present invention is that it requires no kernel modifications and works in Java which is a widely^ieployed 
language. 

[0005] US Application Serial Number 08/852,263 entitled A Process for Running Objects Remotely filed on May 7 
1997 and assigned to the assignee of the present invention. 

[0006] US Application Serial Number 08/941 ,815 entitled Apparatus and Method for Dynamically Modify ing Cfass 
Files During Loading for Execution filed on September 30, 1 997 and assigned to the assignee of the present invention 
[0007] According to one aspect of the present invention there is provided a method for dynamically distributing objects 
of a program, each object containing one or more programmed entities, from a first computer to one or more remote 
computers, said program having one or more objects, said method comprising the steps of: 

identifying all of the objects in said program; 

creating a list of conditions under which objects of said program are to be migrated; 

for each object to be migratable, identifying each programmed entity to be accessed from outside of the object- 
generating a first proxy and a second proxy for each object that may be moved to or accessed from a remote 
computer, said first proxy residing on the same physical device as said initial object and said second proxy created 
on said same physical device and transferred to said remote computer upon object migration, wherein said first 
proxy contains network linkage and indication to access said programmed entities on said remote computers and 
said second proxy contains network linkage and indication to access said programmed entities on said first com- 
puter; and, 

moving an object from said first computer to a remote computer when said object s corresponding condition from 
said list of conditions is met. 



[0008] According to a second aspect of the present invention there is provided computer readable code for dynam- 
ically distributing objects of a program, each object containing one or more programmed entities, from a first computer 
to one or more remote computers, said program having one or more objects, comprising: 

first subprocesses for identifying all of the objects in said program; 

second subprocesses for creating a list of conditions under which objects of said program are to be migrated; 
subprocesses, responsive to said first and second subprocesses, for each object to be migratable, for identifying 
each programmed entity to be accessed from outside of the object; ~ 
subprocesses, responsive to said first and second subprocesses, for generating a first proxy and a second proxy 
for each object that may be moved to or accessed from a remote computer, said first proxy residing on the same 
physical device as said initial object and said second proxy created on said same physical device, and transferred 
to said remote computer upon object migration, wherein said first proxy contains network linkage and indication 
to access said programmed entities on said remote computers and said second proxy contains network linkage 
and indication to access said programmed entities on said first computer; and, 

subsequent subprocesses for moving an object from said first computer to a remote computer when said object s 
corresponding condition from said list of conditions is met. 
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AOD allows a programmer or system administrator to determine at any time before a program begins executing, how 
the program should be distributed onto a client and a server computer. AOD then automatically creates the code that 
allows the application to run as a distributed application. 

[0030] However, as described in the AOD invention referenced above, AOD does not permit objects to be migrated 
between client and server at run-time. It requires the distribution to be complete prior to execution. It would be beneficial 
to move objects during runtime to adjust to varying conditions such as server load. That is, when the server becomes 
busier, more classes are moved to the client, reducing the server load. In the present invention an enhancement to 
AOD that allows objects to be moved during runtime is described. 

[0031] First, the following example is used to review AOD. Consider an object 'a* instantiated from class A that 
contains (has a reference to) an object b instantiated from class B. B has a method foo(). Exemplary pseudocode for 
this situation is: 



class A { 
A () { 

// constructor for A 

) 

soroe_method ( ) { ^ 

B b = new B (); // allocate object b 
b.foo(); // call foo method on b 

) 

} 

class B { 
B () { 

// constructor for B 

} 

foo () { // foo performs some action 
) 

} 

[0032] 'If the programmer determined that 'a* was to be split from b, the process would generate two proxies for B, 
B 1 and B". Calls from 'a* to *b' would be intercepted by B\ passed across the network to B" whiwh then makes a local 
call to B, passing the results back as necessary. Note that once this configuration has been established , it cannot be 
altered at run-time. 

[0033] Dynamic Object Distribution (DOD) is an enhancement to AOD. In DOD, the programmer identifies not only 
which classes should initially be on the client, and which should initially be on the server, but also which classes might 
be moved dynamically from one to the other. This identification as to which classes might be moved can be made any 
time up until the program is run. The programmer identifies these classes not by changing the program itself (this is 
known art, see below), but by (e.g.) typing the list into a separate file. Other methods of specification will be apparent 
to those skilled in the art. At run time, programmer-specified "predicates" are used to trigger the automatic migration 
of the objects. 

[0034] The DOD process is comprised of the following steps. These steps, as the preferred embodiment of current 
invention, are expressed in the Java programming language and execution environment, although other embodiments 
in other object-oriented programming systems are possible. 

1) Writing the classes comprising an application in the Java programming language. 

2) Compiling the source Java files into Java bytecode files. 

3) Identifying which objects are available to be moved. 

4) Specifying predicates (conditions) under which an object might move. 

5) Specifying initial execution locations for objects instantiated from each class in the system. 

6) Generating the local and remote migration proxies (described below). 

[0035] The user then starts the program. As the program executes, the DOD process automatically moves objects 
when the predicates of step 4 are satisfied. 

[0036] In addition to each of these steps, DOD contains a "migration thread." This thread is responsible for monitoring 
system resources to determine when the predicates (described in step 4, and further described below) have been 
satisfied. It also initiates object migration. 

[0037] This process is now described in further detail. Steps 1 and 2 are standard parts of the application development 
for Java. In prior implementations, after step 2, the application would be executed by a user. However, that application 
would lack the ability to move objects dynamically. 
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[0038] Next, the classes that the developer desires to be mobile are identified. Objects instantiated from mobile 
classes are candidates for migration by DOD. if the programmer chooses not to enter any list, then DOD assumes that 
all objects can be migrated. Thus, by default, the programmer neednl make any source changes, nor need he do any 
additional work to enable object migration. This is a departure from known art. However, as we describe below, pre- 
s paring an object for possible migration entails system overhead. The programmer can reduce this overhead by noting 
which objects will not be migrated. Still, requiring no changes to the program, even if a separate listing is required, 
provides significant benefit over the current art. 

[0039] In step 4, the predicates are specified. These predicates are used to control the dynamic behavior of the 
system. The programmer identifies the conditions under which objects are migrated. For example, if objects designated 
10 01 through 09 are to be executed on the server, the programmer can specify that DOD is to migrate O! and 02 if the 
server toad exceeds some threshold T1 ; 03, 04 and 05 are to be migrated if it exceeds T2; and 06 is to be migrated 
if it exceeds T3. 07, 08 and 09 are not migrated. In the preferred embodiment, this information is simply specified in 
a file called the 'migration file, - although other specification methods are clearly possible and would be obvious to one 
skilled in the art. 

is [0040] Note that migration files may be specified on a per user basis as well as on a more global basis. That is, in 
the preferred embodiment, each version of the migration file (alternatively; each section within a single migration file) 
is associated with one or more users of the application. Thus, the application can optionally exhibit different behavior 
when executed by different users. 

[0041] Step 5 designates the initial configuration for the system. That is, the programmer tells the system which 
20 classes spawn server objects, and which spawn client objects. In the preferred embodiment, this information is also 

stored in the migration file. 

[0042] An example of a migration file might be: 

Userl MyClassOne CPU > .5 # move if CPU over half utilized 

Userl MyClassTwo CPU > .7 # move if CPU over 70% utilized 
25 Userl MyClassThree CPU > .9 # move if CPU over 90% utilized 

Userl MylOCIassOne Disk < .4 # move if disk is 60% full 

Userl MylOCIassTwo Disk < .2 # move if disk is 80% full ('#' indicates the beginning of a comment; subsequent text 
on the line is ignored.) 

[0043] Generating the local and remote proxies is one key to the DOD system. This is illustrated by example. Re- 
30 turning to a modified version of the example shown above, assume that objects 'a' and V are co-resident, and the 
programmer identified objects instantiated from B as migration candidates. DOD reads the bytecode for class B (of 
which 'b' is an instance) and determines all of its public methods. As in AOD, DOD generates a proxy for B called B\ 
All calls to B are then indirected through B*. In the case of local calls, the call sequence is A B' -> B. In the case of 
remote calls, as in AOD, the sequence is A -> B* -> B m -> B. 
35 [0044] B' is then constructed to allow both local and remote calls. In exemplary pseudocode, B' looks like: 



boolean local = TRUE; // object starts local 
B () { // constructor for the proxy for B 
create a reference to the real B 
) 

foo () ( 

if (local) make local call to the local foo(); 
else make remote call to foo as described in AOD 

) 



[0045] As shown below, to each proxy, code must be added to migrate the object. In addition, code must be added 
that protects method calls against timing conflicts - that is, calls against methods in the object are not permitted while 

50 the object is migrating. This is done by making the proxy class "synchronized," (a standard Java term) thus protecting 
the class against race conditions, and adding a migration method. Finally, the local proxy must register itself with the 
migration thread. This allows the migration thread to locate the proxy when an object must be migrated. 
[0040] Each proxy is constructed such that it implements the Migratable interface. This allows the migration thread 
s register method to accept a single type of object as a parameter, that is, a proxy class implementing the Migration 

55 interfac . The migration thread s register method then stores references to the parameters (proxy objects) in a table 
for use when an object must be migrated. 
[0047] Thus B' becomes: 
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synchronized class B implements Migratable ( 
boolean local = TRUE; // object starts local 
B () { // constructor for the proxy for B 
create a reference to the real B 
register with the migration thread 

migrate ( ) { 

serialize the "real* b- 

"^in^^isJin^ater^ V " * ^ <° the **ere it 

local = FALSE; 

} 

£00 () ( 

it (local) make local call to the "real" food- 
else make remote call to foo as described in AOD 

} : 



[0048] Note that since the proxy object B' is synchronized, by standard Java semantics the mixtion m**^ 

[0049] Serialization 0* an object, and passing serialized objects over sockets is well-known art in Java After the 
object is serialized and sent over the network (using a standard Java method called writeObject ) »££e£££l 
DOD component on the remote computer using another standard Java method ( readObjed^ ^e unseri^ize^obiert 
is now ready to execute on the remote computer J 1 ne unse "a"2ed object 

[0051] This apparent problem is solved by identifying those classes that were listed by the user as mobile h.t h« 

£ Z^r^TT^ in,erface Using a by,ecode ™ «* 

he patent application designated above entitled Apparatus and MethnH to ny n^uy w-,^ c|a ^ n^J" 
£££ Bg^V ,r T S, 0 0r,nati0n fe that at the point when toe class b^SggS JvM ma ks 

tne 2™ T^T"? Sena,,Zab,e htertace - * ,WS ,he execulion «" P^eed as usual Note thaS 
th^^ 

tool, the programmer ,s not required to do anting, and no change to the source code occurs UsinqasiX mJT 
an«m parameter objects can be made ,0 implement the Seria.izable Menace if they must to ££, 

iiSTTF* r ,9Ure K 4 " IUStra,eS ,he Pf0CeSS ° f pfOXy 9enera,ion — bytecode modification 
[0052] In Figure 4. an object 401 is processed by a proxy generator 403. The proxy generator creates a local oro*v 
405 and a remote proxy 407as well as retaining the unmodified object 401 The bvtecode modHfe <Z *~ P ^ 
the unmodified object 401 to create a serializable object 411 from it ^ processes 

fjf 3 - ■ A f i -^"T fem0te PfOXy (BV in ,he example > acce P 1s 03,18 < r <™ "ocal proxy, and makes local calls to 
he original object (B). In addition, the remote proxy must include code to redirect calte f romThe Z to tntuoh 
the remote proxy, through the local proxy, and finally to the callee J 9 

f^on a ^ I"".!!' 8ted in Fi9UrS 5 ' ,he Pf0CeSS ° f 9enera,in9 for re,urn « ve* similar to the process used 
l^fZ n ? P r 8S ! hefe '°' i " COming 03,18 ^ b y ,ecodes for the Migratable object are 2 
afi method calls to other objects are extracted. For each such call, both a local prox^ 510 and iTemote 7Z So am 

Zw^ 

SIT! J * ' 3 rem ° ,e (RMI) 0811 ,0 toCal prOXy is executed - Code in kxa' P">* ens^etZ 

TZt Z e " eS 3 : em0,e Ca "' if 3 ,OCa ' 0311 10 ,he ac,ual caltee - ^us, this process is nearly IntS , 0 the 
process for generating proxies for incoming calls, except that the object is inspected for outgoings ins 2d 6, to 

[0055] Migrating the object back to the local machine simply entails reversing the process The process is initio 

r^o^ 

[0056] It is important to ensure that timing problems do not occur during unmiqration Because the kv^i n™, 1 
synchron,zed, ^e call ,0 the unmigrate method will not execute (that is, i, J, block) u "a t^whenTw^e 
method executmg ,n the local proxy. Since all calls to the remote callee must pass through theTS. p^xy JeZw 
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that the remote callee will not be executing when the emigration occurs. The emigrate method on the local oroxv 
8,mp.y ca.te the migrate method on the remote proxy. The call to the emigrate method on the kx^proxyooes^ 
complete until the entire migration is complete. P ^ s 001 

[0057] The migrate method on the remote proxy performs the same function the migrate method on the local proxy 
KpTxy^ 

[0058] In the ongoing example, B* becomes: 



10 synchronized class B { 

k°^ e * n loca * = TRUE; // object starts local 
B () ( // constructor for the proxy for B 

create a reference to the real B 
^register with the migration thread 

75 - unmigrate () ( 

make a remote call to migrate on the remote proxv 
receive the serialized object Proxy 
unserialize the object 
local = TRUE; 
return; 

20 ) 

migrate () { 

serialize the "real - b; 



25 



30 



send the serialized obiect vi* * o^u<>i- _ 

will be instantiated SOCket t0 the ^ rt ner where it 

local = FALSE; 

) 

foo () { 



} 



if (local) make local call to the -real- foot)- 
else make remote call to foo as described £°MD 



[0059] TTie user then simply starts the system as they would any client/server Java application As the application 
the predicates specified h the migration file. When a predicate ^^Z^S^Si 
threshold is satisfied), the migration process is triggered. 

22L * ,h t, mi9ration ' When *» mi 9 ra,ion ,hread °» ^ DOD process detects that a predicate has been 

f^' m '9ration file is used to determine which objects are to be moved or migrated. They then call the rn^qration 

[OKI] The migration method on the local proxy serializes the object, it s proxies and the proxies of any objects which 
t calls and sends rt to the remote node for execution. The JVM on the remote machine calls the ■Read^rS 
? ? ab T-.'r a r69iSterS the remote ?™ ies *»• the Remote Method Invocation (RMI) R^iZ 
Uniques for reading ,and wrrtmg senalfeed objects across a network via a TCP/IP socket and for inte acting wS 

[0062] The local proxy, as described above, is constructed such that it contains all of the public methods contained 
by the object which rt ,s proxying. Each of these methods either caUs a method on the actual object (if E«SS5 
s£*l) or remotely calls (via RMI) a method on the remote object (if the object was migrated and is now remote) 

SSL l^h » T 9 ^ '° r ^ ^ th3t CallS th9 mi9ratable ^ ,he P rox v to** the name of the 
Object for which rt is acting as a proxy. Thus, any calls originally destined for the migratable objects will be retargeted 
at the proxy simply by the standard Java semantics. J retargeted 

ESS ^^1^ ^^"^^^oh^tohavethesamename. In the case where the object is executing 
PrOXy ^ bem9 PfOXied Wi " h8We ,h6 ^ name 71,81 b ^Permissible. To rectify the 

Pr0C T B 6XeCUted Usin9 3 Dy1eCOde modifica,i °" tod. the original (migratable object)Ts re- 
named by appendmg an arbitrary string to its name in its bytecode file. The constructors for the class are renamed 
similar^ The proxy then makes calls to this newly named object. renamed 
[0065] For example, consider the code fragment Irom above: 
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class A ( 
A {> { 

// constructor for A 

} 

5 some_method () { 

B b = new B (); // allocate object b 
b.fooO; // call foo method on b 

) 

class B { 
W B () { 

// constructor for B 

} 

foo () { 

// foo performs some action 

15 * } 



?5 



0 



) 



} 



T?i«f ea ^K a ^ OXy f ° r ?' first B is "named in its bytecode ("class- 
file), then the proxy is created: y ( class 

class Bwxyz { // this is the real, renamed B 
Bwxyz {) { 

// constructor for the real class 

foo () { 

// foo performs some action 

} 

synchronized class B { // this is the proxy for B 
Bwxyz myBwxyz; // reference to the original object 
B () { // constructor for B 

} 3&s r \ss: s?i&(i. B gs a - new ° bject ** the ***** « 
^uy/foSij" fo ° on the renamed versi ° n ° f the b 

'ISuiii.'tii 5jSr?: ° bjeCt mi9rati ° n Code " »V »i 9 r. thread 

local = FALSE; 

} 

unmigrate ( ) { 

make a remote call to migrate on the remote proxy 
leceive the serialized object f*w*y 
unserialize the object 
local = TRUE; 
return; 

) 



[0066] The call from A to "B.foo" now refers to the "foo" method in the proxy object B. Thus, the B proxy has suc- 
cessfully intercepted calls to B. In turn, the B proxy makes calls through its reference to the original B. 
[0067] Figure 2a shows a simple object oriented program comprised of 3 objects, A, B and C. Object A has three 
methods labeled a1-a3; B has four methods labeled b1-b4; and Object C has two methods labeled d and c2. As 
indicated in the figure, the following method calls exist: 
a1 calls b3 and b4 
a2 calls b2 
b2 calls c2 
d calls a2 

[0068] Figure 2b depicts the same program after the programmer has specified that C is the only migratable object. 
The system automatically generated a local proxy specified in the figure as CL, containing two methods specified as 
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cl1 and c!2. Note that, per the discussion of naming conflicts, the local oroxv and it« mofh^ 
original names of the object and its methods; the original object ^ ESS oil """" *** the 
(object renaming is not illustrated in the fio.,mi ' S renan)ed b V bytecode modification tool 



(object renaming is not illustrated in the figure). 

[0069] The method call list is thus adjusted to 
5 a1 calls b3 and b4 

a2 calls b2 

b2 calls cI2 

cl2 calls c2 

cl1 calls d (unused) 
10 c1 calls a2 



75 



[0070] • Since this is a local configuration, calls from the caller r a n m or~ i * 

are directed to the callee (C) via a standard methoW 9 " ' ' n,ercepted b * P™Y (CL) and 

[0071] Figure 2c shows the migration thread detecting a satisfied credit *nri <^~r 

method in the local proxy for C (CL). This causes the m^^r ^T ™ 9 a meSSage to ^Re- 

configuration illustrated in figure 3 9 t0 the rem ° te machlne « *« the ^sitfon to the 

Sb^ 



a1 calls b3 and b4 
a2 calls b2 

// Call from b2 to c2 indirected remotely 
b2 calls c!2 

cl2 calls cr2 using RMI 
cr2 calls c2 

// Potential, but unused, calls into d 
cl1 calls cr1 using RMI (unused) 
cr1 calls c1 (unused) 
//Calls fromd toa2 
d calls ar2 

ar2 calls alt using RMI 
a!2 calls a2 
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[0073] As described above, DOD consists of the followinn main «t~ M . ^ 
Potion. Theresultisaset of Java b W eJ^^^^ 

and is not strictly a part of the present^tS * N e* Hh 2 ™« ^ * veto P^"t phase for Java applications, 
condit^s -der'wh^hthey are^^ and the 

modification to ensure that the appropriate classes imn£m!nf,K c T ^ 0,6 StUbs DOD P erfor ms bytecode 
resolved. The stubs contain thec^oTe^^ 

the code necessary to migrate the object. Next the migTa ^ th£^£?T . * " a,S ° COnteins 

when a predicate is satisfied When a predicate is saS^ -..fl fte SyStem resource s- and detemiines 

amigration. Next the migra.icTeTh^ 

mils them to the remote JVM (Java virtual machine) wh^ ih« Sot 9 ^"'^ rem ° ,e proxies ' and trans - 

restarted with its new configuration. *' * ,eClS afS re(ns,anli ^ The application can then be 

[0074] In summary a method and system are described which allow n™» m ..«k 

without programmer interventkx, Tti means that the^oTa^s cTSZ ^°™* namK »>* reconfigure 
puters within a computer network without modifica Z Se ZrTe ^£^7^ mul,i <" e co - 

45 add «™- '"a method and system desenbed a.fow an adlis^^ ™ *• Sys,em ,n 

reconfiguration is to occur without modification to the source text of tt o^am^ h I * ""f^ 5 Und9r Wh ' Ch 

Claims 

method comprising the steps of: computers, said program having one or more objects, said 



method comprising the steps of: 

identifying all of the objects in said program 
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creating a list of conditions under which objects of said program are to be migrated" 
for each object to be migratable, identifying each programmed entity to be accessed from outside of the obiect 
generafmg a first proxy and a second proxy for each object that may be moved to or accessed from a remote 
computer, said first proxy residing on the same physical device as said initial object and said second proxy 
created onsa,d same physical device and transferred to said remote computer upon object migratbn where^ 
sa.d first proxy conta,ns network linkage and indication to access said programmed entities on sartZZ te 

TsaS^ 

f^Tsak^^ 

2. A method as claimed in claim 1 further comprising the steps of: 

identifying which of all of the objects in the program are to be available for migration- 
placing the names of the objects available for migration into a list; and, 
utilizing said list as input to the distributbn method. 

moving a copy of said object to said remote computer; 

moving said second proxy to said remote computer; and, 

directing said first proxy to call said second proxy on said remote computer. 

4. Computer readable code for dynamically distributing objects of a program, each object containing one or more 

3 flfSt C ° mPlJtef tC ^ * ^ rGm ° te C ° mpUterS ' *** ™™ havi "9 ™ - 
first subprocesses for identifying all of the objects in said program 

second subprocesses for creating a list of conditions under which objects of said program are to be migrated 
subprocesses. responsive to said first and second subprocesses. for each object to be migratabte for idenH- 
fymg each programmed entity to be accessed from outside of the object- 

subprocesses. responsive to said first and second subprocesses, for generating a fire, proxy and a second 

^ZT ^ ^ m8y ^ ^ ,0 W 8CCeSSed ,rom a remote compute" said firs, proxy resid^ 
the same physical dev.ce as sa.d mrtial object and said second proxy created on said same physical device 
and transferred to sakt remote computer upon object migration, wherein said firs, proxy c^tonTneZ* 
finkage and ,nd,ca„on to access said programmed entities on said remote computers and said second proxy 
con,ams network linkage and ( nd,cation to access said programmed entities on said first computer- and 
subsequent subprocesses for moving an object from said first computer to a remote computer when said object 
s corresponding condition from said list of conditions is met. ' 

. Computer readable code as described in claim 4 further comprising: 

subprocesses responsive to said first subprocesses. for identifying which of all of the objects in the program 
are to be available for migration; K «w« ■ 

subprocesses, for placing the names of the objects available for migration into a list and 
subprocesses for utilizing said list as input to the distribution method. 

Computer readable code as described in either claim 4 or claim 5 wherein said moving of an object from said first 
computer to a remote computer comprises: 

subprocesses for moving a copy of said object to said remote computer; 

subprocesses for moving said second proxy to said remote computer and 

subprocesses for directing said firs, proxy to call said second proxy on said remote computer. 

A system contained within a computer network, said computer networx having multiple computers connected to- 
gether using ,e.ecommunica,ions mechanisms, said sys,em having a method for dynamica.fy distrZngljeci 
ofaprogram. each object Gaining one or more programmed en.rties, from a firs, cLputer.Le or S 
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computers, said program having one or more objects, comprising: 
means for identifying all of the objects in said program; 

means for creating a list of conditions under which objects of said program are to be migrated" 
o?.hTob|2r t0 mi9fa,able ' meanS for ^ Programmed entity to be accessed from outside 

means for generating a first proxy and a second proxy for each object that may be moved to or accessed from 
a remote computer, sa.d first proxy residing on the same physical device as said initial object aSSSSS 
proxy created on sad same physical device and transferred to said remote computer urL cSJmtaS? 
where-n sa,d first proxy contains network linkage and indication to access said programed •KXS 
remote computers and said second proxy con.ans network linkage and indk^ to access sakTprogramrS 
entities on said first computer; and, Programmed 

means for moving an object from said first computer to a remote computer when said object s corresponds 
condition from said list of conditions is met. wrresponamg 

A system as described in claim 7 further comprising: 

means for identifying which of all of the objects in the program are to be available for migration- 
means for placing the names of the objects available for migration into a list and 
means for utilizing said list as input to the distribution method. 

^cr^p^ 

means for moving a copy of said object to said remote computer; 

means for moving said second proxy to said remote computer; and 

means for directing said first proxy to call said second proxy on said remote computer. 
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Fig. 1a 




Prior Art 



Fig. 1 b 

network boundary 




Prior Art 

Fig. 1 c 
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Fig. 2a 
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Fig. 2b 
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Fig. 2c 
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do forever { 
check for object registration 
check computer resource usage 
compare usages to predicates 
if a predicate is satisfied { 

check list of registered objects, initiating migration for 

those whose predicate was satisfied 

} 

} 



Fig. 6 
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Fig. 7 
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